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The essential elements of the design process 
consist of the mission definition phase that 
provides the system requirements, the con- 
ceptual design, the preliminary design and 
finally the detailed design (Figure 1). Mis- 
sion definition is performed largely by oper- 
ations analysts in conjunction with the cus- 
tomer. The result of their study is handed off 
to the systems engineers for documentation 
as the systems requirements. The document 
that provides these requirements is the basis 
for the further design work of the design en- 
gineers at the Lockheed-Georgia Company. 

The design phase actually begins with 
conceptual design, which is generally con- 
ducted by a small group of engineers using 
multidisciplinary design programs. Because 
of the complexity of the design problem, the 
analyses are relatively simple and generally 
dependent on parametric analyses of the con- 
figuration. The result of this phase is a base- 
line configuration from which preliminary 
design may be initiated. 


Preliminary design is far more complicat- 
ed, both because the analysis techniques are 
more complex, and also because these tech- 
niques require specialized knowledge. The 
objective of this step is to refine the design 
estimates made during conceptual design 
and to add additional detail to the descrip- 
tion of the configuration. At the conclusion 
of this phase, the aircraft is defined well 
enough so that a company can comfortably 
bid the cost of producing it. 

Detail design is largely mechanical in na- 
ture, and normally occurs after receipt of an 
order for production. This is not an area of 
concentration in this presentation, however. 

To provide a basis for amplification of the 
conceptual design process, look at Figure 2. 
The function of the conceptual design process 
is to conduct a multidisciplinary analysis of 
an aircraft to produce values of parameters 
that describe an aircraft. These parameters 
are top level descriptions that leave most of 
the actual configuration details undefined. 
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Figure 1 Essential Elements of the Design Process 
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However, implicit in this process is the 
trading of factors that relate to the perfor- 
mance of the configuration. The trades I 
mean are typified by the thinness of a wing 
desired by an aerodynamicist versus the 
thickness of a wing as desired by a structural 
analyst. 


investigated to ensure that a true optimum 
had been found. This old procedure was also 
tedious. All data had to be manipulated man- 
ually. Although this did provide useful in- 
sight to the designer, the cost was a further 
delay. Dozens of computer runs had to be 
scanned, the results judged for correctness, 
and the results plotted on carpet plots. Many 



Figure 2 Conceptual Design 

Typical parameters defined at this stage 
are fuselage length and width, wing area, 
sweep, aspect ratio and, to a limited extent, 
control surface. 

In former times, conceptual design was 
manually directed and highly iterative. The 
process consisted of guessing an initial con- 
figuration, analyzing that configuration, and 
then systematically varying each of several 
design parameters to examine a design space 
within which manual optimization could 
take place. Normally the number of param- 
eters examined did not exceed four, because 
of the human limitations in absorbing more 
variations than that. There were several 
disadvantages to the former approach. This 
process was time consuming, fallible and 
tedious. It was time consuming because the 
answer depended on many executions of a 
computer code. It was fallible because the 
choice of the parameter variation to be exam- 
ined was entirely at the discretion of the 
designer. Thus, the quality of the answers 
was directly dependent on the skill of that 
designer. In addition, no one could be sure 
that a large enough design space had been 


The former process was basically elimi- 
nated at Lockheed-Georgia several years 
ago, in favor of the approach shown here, 
based entirely on numerical optimization. 
The new process is described schematically 
here (Figure 3). The former process was usu- 
ally completed in one day. Many of the man- 
ual actions have been eliminated. Now, a 
given study may consume as much time as 
formerly, but a much larger range of design 
variables has been included. 

Preliminary design process 
(Partial) 

The next step in the design process is pre- 
liminary design. This is the process, partially 
illustrated in Figure 4, by which the concep- 
tual design baseline is analyzed in greater 
depth to confirm the design or provide foun- 
dation for changing the design. This process 
is typified by the more or less simultaneous 
execution of many detailed design codes in 
several disciplines. Obviously, the communi- 
cation during the process is difficult, and the 
designs proposed by each discipline are fre- 
quently inconsistent. Iterative loops, while 
very common, cannot be represented because 
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Figure 4 Preliminary Design Process 


of the indeterminate sequence of such iter- 
ation. 

As an example of the type of analysis con- 
ducted in this phase, consider aerodynamics 
for a moment. The codes frequently applied 
in this phase consist of full potential subsonic 
or transonic codes for configuration analysis, 
full potential codes for direct design, and 
Navier-Stokes codes for highly complex vis- 
cous flow analyses. As a result of the aerody- 
namic analysis done during this phase of 
design, the wing external contours are fully 
defined and more reliable estimates of the 
vehicle performance are available. Similar 
refinements and definition are added by each 
of the participating disciplines. 

The deficiencies of the current approach 
are immediately obvious. First and foremost, 
the result is a suboptimal configuration. 
Even though optimization may be used 
within isolated analyses, the difficulty of 
communication in real-time and the lack of 
available tradeoff criteria mean that no glo- 
bal, rigorous optimization occurs. 

I have already alluded to the use of opti- 
mization on individual analyses in this 
phase. Here are some examples of such opti- 
mizations. The aerodynamics discipline has 
been very active in developing optimization 
techniques for the design of wings in tran- 
sonic flow, largely based on FLO codes. These 


methods provide a wing shape, starting with 
a specification of a desirable pressure distri- 
bution. Using such methods, the wing con- 
tour and twist distribution may be calculated 
directly. 

Subsonic optimization techniques have 
generally been limited to the design of high 
lift systems. In this case, the optimal location 
of a slotted trailing edge flap can be found by 
optimizing on the axial force for the system 
and by using paneling methods for calculat- 
ing the flap system pressure distribution. 

Structural optimization has been done for 
minimizing structural weight, given loading 
conditions. In this case, the structure is mod- 
eled using finite element techniques, with 
element geometries such as thicknesses or 
cross sectional areas taken as design vari- 
ables. Another example of structural opti- 
mization is in the design of composite panels. 
The objective is to determine the ply orienta- 
tion to respond to specific loading conditions. 

If I were to summarize the preliminary 
design optimization work currently being 
done at Lockheed-Georgia, I would have to 
say that its use is relatively new, that it has 
been very well accepted, and that its use is 
certainly increasing. But this may eventual- 
ly become a severe problem for us, since the 
optimization is being applied to subprocesses 
within design. Worse yet, it is being applied 
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Figure 5 Proposed Preliminary Design Process 


to old design philosophies. The result has to 
be suboptimal designs. 

The preliminary design process is clearly 
another candidate for improvement by opti- 
mization. The technical challenge of this 
problem is much greater that that of the con- 
ceptual design process, but the potential pay- 
off is also much larger. The challenge comes, 
in part, from the large number of individuals 
and computer programs normally invoked at 
this design state, and the current dearth of 
technology available to solve the very differ- 
ent problems thus posed. 

One possible way to apply optimization in 
the preliminary design process is shown 
here. The fundamental idea is that candidate 
design parameters flow downward to the in- 
dividual analysis modules and the result of 
the analysis flows back up to the optimizer. 

Obviously, such a system is far from reali- 
ty. The technical challenges outweigh those 
of optimization itself. The analysis methods 
normally used in preliminary design are 
state-of-the-art methods that are time con- 
suming, user-sensitive and modeling sensi- 
tive. Because of this, not only will new 
optimization techniques be needed, but so 
will entirely new operational procedures. For 
example, optimization now is executed most- 
ly as a black box program. The analysis 
points provided by support codes are consid- 
ered to be correct and not subject to code 


sensitivities. In the preliminary design pro- 
cess illustrated here, the former approach 
clearly will not work. The new process must 
include a method for disciplinary engineers 
to examine the analysis code results as they 
are being generated to ensure that the opti- 
mized results are valid. When such an opti- 
mization method is available, however, I 
submit that the problem is far from finished. 
This is so because people inevitably are the 
designers, and the design techniques, wheth- 
er through optimization or not, must take the 
human element into consideration. 

Systems Engineering - a Definition 

To expand on this theme, let me begin be giv- 
ing you my orientation. I am in the Systems 
Engineering Department at Lockheed- 
Georgia. This gives a reasonable definition of 
what Systems Engineering means to us: a 
discipline that coordinates the engineering 
activities within large organizations to help 
produce a superior, cost-effective, timely 
product. By its very definition, it is a process 
of dealing with people in a large design op- 
eration. As such, our interest is not in the 
internal working of design codes, but rather 
in how individuals use given design codes to 
produce designs, and then how those indi- 
viduals transmit their information to other 
designers in the organization. 
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Let me present the four main tasks of the 
Systems Engineering operation. They 
involve the management of trade studies, re- 
quirements, interfaces and technical risk. 
Another way to express these four tasks is 
Communication, Communication, Communi- 
cation, Communication. 

Decisions are the design process. By its 
very nature, design requires definition of 
some configuration from an infinity of possi- 
bilities. The best design is some compromise 
of many and widely varying constraints. 
Many times the choices to be made are 
aesthetic, or subjective, or not amenable to 
computer analysis. In these situations, and 
sometimes even in well-defined engineering 
choices, trade studies must be performed that 
are outside the domain of the optimization 
process. 



Figure 6 Hierarchy of Decisions to Select a 
Navigation System for an Airplane 


The illustration above (Figure 6) is a sim- 
ple representation of the decisions that 
might be made to select a navigation system 
for an airplane. These choices are displayed 
as a hierarchy, beginning with the top level 
vehicle considerations, and then working 
downward to finer levels of detail. Systems 
Engineering is responsible for generating 
such a trade tree to illustrate the decisions to 
be made, defining the design groups to be 


involved, coordinating the studies needed, 
and documenting the result. 

Some of the decisions illustrated in this 
trade tree are supported by optimized meth- 
ods. For example, the vehicle may be initial- 
ly sized with optimization, and components 
may also be designed with optimized meth- 
ods. Nonetheless, when design decisions are 
to be made, there is a high likelihood that not 
all the decisions will have been supported 
through optimization. The point is, optimiz- 
ation methods are embedded in the total 
design process, and this must be taken into 
account in the development of these optimiz- 
ation methods. 

This last feature is what I am trying to 
illustrate in Figure 7, Some decisions of the 
design process will be made within the opti- 
mization process. Some will not. But those 
that do not must have information available 
from the optimization to assist the manual 
decision-making process. This is true wheth- 
er the outside decision is being made concur- 
rently with the optimization or whether it 
lags the optimization by days, weeks or 
months. 



The implication is that information more 
comprehensive than just the final optimized 
configuration must be provided and stored. 
Possible information needs include sensitivi- 
ties around the optimal point and the 
optimization history. In addition, it will be 
necessary to provide a way to interrupt the 
optimization process as it is occurring to 
input new information to the optimization 
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process and to influence, on the fly, the out- 
come. 

Requirements Flowdown 

Let me provide one more example, that of 
requirements flowdown. This is another ex- 
ample of the communication involved in the 
design process. In this case, the objective is to 
communicate to each individual designer the 
importance of design in meeting the top level 
performance requirements. This is done by 
analyzing the top level system requirements 
and assigning or allocating these top level re- 
quirements to the next lower level to deter- 
mine the drivers in the system. This process 
is repeated to successively lower levels until 
the final objective is accomplished. That is, 
the question “What is each individual’s con- 
tribution to the total system performance?” 
is answered at the lowest logical level. 

A specific performance might be mainten- 
ance manhours per flight hour, or it might be 


minimum range requirements. Whatever the 
requirement, this process allocates it to the 
lowest level of the configuration, maintains 
the traceability to the top level requirement 
and assures that the total system require- 
ment will be met. 

The question is, “What is a proper alloca- 
tion?” If a top level requirement is rippled to 
the lowest level, which functional area 
should contribute what proportion to the 
final performance? If we rely on a optimiz- 
ation process that merely gives a final an- 
swer, we are blind. This is another case of not 
all functions being included in the optimiz- 
ation process. For these “outside” functions, 
we have no sensitivity information upon 
which to base realistic allocations. The actu- 
al situation might be as illustrated here, 
where the cost of attaining a given level of 
performance varies greatly from one disci- 
pline to another. I have used cost as the mea- 
sure, but I could have used any measure of 
merit. For the illustration I have given, the 



Figure 8 Requirements Flowdown 
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Figure 9 Optimize Allocations 


optimal allocation of the requirement is that 
which simultaneously attains the top level 
system performance and minimizes the cost. 
In the future, our optimization processes 
must provide visibility for such data. 

I have attempted to illustrate that opti- 
mization has a role in our design process, 
both today and in the future. The benefits are 
well known already, but I believe that we are 
only seeing the proverbial tip of the iceberg. 

Optimization must, however, continue to 
be sold and this selling is best done by consis- 
tent good performance. For this good perfor- 
mance to occur, the future approaches must 
be clearly thought out so that the optimiz- 
ation methods solve the problems that actu- 


ally occur during design. The visibility of the 
design process must be maintained as fur- 
ther developments are proposed. Careful at- 
tention must be given to the management of 
data in the optimization process, both for 
technical reasons and for administrative 
purposes. Finally, to satisfy program needs, 
provisions must be included to give data to 
support program decisions, and to communi- 
cate with design processes outside of the opti- 
mization process. 

If we fail to adequately consider all of 
these needs, the future acceptance of optimiz- 
ation will be impeded. We simply cannot 
allow that to happen. Optimization is too 
important. 
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